home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 10802 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  7.3 KB
  1. Path: news.halcyon.com!usenet
  2. From: normanb@halcyon.com (Norm Bryar)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: Sun, 10 Mar 1996 17:19:26 GMT
  6. Organization: Northwest Nexus Inc.
  7. Message-ID: <4hv2tm$e93@news.halcyon.com>
  8. References: <4hj8ek$elu@sam.inforamp.net> <4hjh5c$elk@flood.weeg.uiowa.edu>
  9. NNTP-Posting-Host: blv-pm10-ip17.halcyon.com
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. Comments with <=== appended
  13.  
  14. maclenna@ozone.uiowa.edu (Mark MacLennan) wrote:
  15.  
  16. >In article <4hj8ek$elu@sam.inforamp.net>
  17. >rmorin@inforamp.net (Randy Charles Morin) writes:
  18. >>The company I just started a contract with gave me a set of C++ coding 
  19. >>standards.  I started reading and couldn't stop laughing.  I can't reproduce 
  20. >>them word-for-word, because that wouldn't be nice to the authors and might be 
  21. >>considered a copyright violation or privacy violation, but I'll outline some 
  22. >>of the points.
  23.  
  24. >Some of their coding standards requirements you list are actually
  25. >quite good, some are more dubious.  Most coding standards are intended
  26. >as guidelines to be followed unless common sense dicticates otherwise
  27. >(and these deviations are documented accordingly).  You should probably
  28. >discuss this with the company, inquire as to the intent of some of
  29. >the standards, rather than laugh behind their back.
  30.  
  31. >Some of the items you list reveal your own unfamiliarity with C++,
  32. >which is perhaps one reason they have defined a set of C++ coding
  33. >standards. (Hopefully the company isn't paying you based on spelling ...)
  34.  
  35. >- MARK
  36.  
  37. >>
  38. >>    -source files should have the extension .cc (not .cpp or .c).
  39. >>    -header files should have the extension .hh (not .hpp or .h).
  40. >>    -inline C++ functions should be in a file with the extension .icc 
  41. >>           (not in the primary header).
  42.  
  43. >The latter is a little unusual but no big deal.  They can always
  44. >edit things how they like later.
  45.  
  46. >>    -do not use the /* */ comment, except when commenting out entire 
  47. >>sections of code.  My understanding is that /* */ comments are ANSI comments, 
  48. >>while // comments are not ANSI.
  49.  
  50. >Your understanding is wrong.  Both forms are acceptable.
  51.  
  52. >>    -a class which can be instantiated with a "new" must have a copy 
  53. >>constructor, a destructor and an assignment operator definition.  This will 
  54. >>extend the project another month. 
  55.  
  56. >Huh?  It isn't that hard to do - maybe the company is planning ahead
  57. >and anticipating the re-use of these classes by other programmers.
  58.  
  59. >>    -never use #define instead or const.  What if your concerned about the 
  60. >>mix between code space and data space.
  61.  
  62. >Not bad advice.  Pre-processor directives should be avoided if possible.
  63. >Better error checking too.
  64.  
  65. Except you can't put consts in a header for everyone to use and you
  66. can't bitwise-OR enum values.  #defines still have a place.    <===
  67.  
  68. >>    -variable are to be declared with the smallest possible scope.
  69. >>        void c::f() 
  70. >>        { 
  71. >>            {
  72. >>                int b; 
  73. >>                {
  74. >>                    int a;
  75. >>                    a=b+c; 
  76. >>                    b=a+d; 
  77. >>                }
  78. >>                e=b+d; 
  79. >>            } 
  80. >>            f=e+4;    
  81. >>        }
  82. >>        this type of optimization could take forever.
  83.  
  84. >Use common sense when applying rules such as this.  In it's strictest
  85. >form it may not be appropriate.  It is a good idea to keep variables
  86. >local to where they are actually used.
  87.  
  88. >>    -don't use explicit type conversions.  In other words, don't program 
  89. >>in windows.  Explicit type conversion is necessary  to convert GDI object 
  90. >>handles.
  91. >>    -don't use implicit type conversions implicitly, use them explicitly. 
  92. >> Hello!
  93.  
  94. >These standards are a little odd but that may be how you worded them.
  95. >Avoiding implicit type conversions is not such a back idea (use casts
  96. >to explicitedly show the conversion).
  97.  
  98. Yes, in Windows programming, type-casts are a way of life and they
  99. shouldn't be implicit and usually can't be implicit if you've #define
  100. STRICT like one should.                        <===
  101.  
  102. BTW, I guess C++ is moving towards phasing-out C-style type-casts in
  103. favor of static_cast<>, dynamic_cast<>, reinterpret_cast<>, etc.   <==
  104.  
  105. >>    -every case statement must be terminated with a break statement.  What 
  106. >>if you want to step through more then one case statement?
  107.  
  108. >Simply document the exception to the rule ...
  109.  
  110. Often you want to return instead of break.  WndProc's come to mind.
  111. That's a rule itching to be broken and, it seems to me, otherwise so
  112. obvious as to not deserve a 'rule'.                              <===
  113.  
  114. >>        case ENGINE_NOT_ACTIVE:
  115. >>            start_engine();
  116. >>        case ENGINE_ACTIVE_NOT_IN_DRIVE:
  117. >>            shift_to_drive();
  118. >>        case ENGINE_ACTIVE_IN DRIVE:
  119. >>            press_accelerator();
  120. >>            break;
  121.  
  122. >>    -don't use conditional compilation preprocessor directives.  There 
  123. >>goes cross-platform development.
  124.  
  125. >Huh?  Since these are pre-processor commands, simply run your code 
  126. >through the pre-processor for the particular platform your client wants
  127. >the software for.  What's the big deal from your point-of-view?  Out-of-
  128. >curiousity, I would inquire as to why they have this programming standard.
  129.  
  130. This is a ludicrous standard.  We always have preprocessor
  131. conditionals in our code, that's how you get diagnostics in _DEBUG,
  132. profiling in PROFILE, and neither in NDEBUG.  That's how you switch
  133. endian for your MAC port, etc.  
  134. Anyone seen how assert() is implemented?                       <===
  135.  
  136. >>    -optimize code only when you have a problem.  So we can't optimize 
  137. >>size in order to anticipate that code size will be a problem.  First we have 
  138. >>to experience the problem (most likely in the field).
  139.  
  140. >Perhaps they want well-written code that they and other
  141. >future programmers can read rather than tricky "optimized" code.
  142. >The code can always be tweaked for specific hardware at a later
  143. >time.  There is no reason that you can't write efficient code using
  144. >appropriate algorithms and data structures.
  145.  
  146. >>    -access functions are to be inline.  Inline access functions defeat 
  147. >>the purpose of having access functions.
  148.  
  149. >This isn't clear.  Having access functions inplemented inline isn't
  150. >such a bad idea.
  151.  
  152. Inline may just mean in the header instead of in the soucefile; inline
  153. and virtual are incompatible, so in-lining is sacrificed in that case.
  154. <==
  155.  
  156. >>    -give protected accessors for all data members.  What if we need to 
  157. >>make the accessor public.  Should we define one protected and one public.
  158.  
  159. >Accessor functions aren't "data members".  Keeping your data isolated
  160. >to a particular class and only accessible through accessor functions
  161. >is a good idea.
  162.  
  163. They must mean accessors to all data-members, protected accessors if
  164. only sub-classes will need the data, public otherwise.   <====
  165.  
  166. >>    -++ and -- operations should be on a separate line.
  167. >>        for (i=0; i<0;
  168. >>            i++
  169. >>        );
  170. >>        Is that better?
  171.  
  172. >Since the ";" is a statement separator and essentially equivalent to 
  173. >their intent of "separate lines" you needn't do the above.  You seem
  174. >to miss the point of this standard - they want to avoid problems with
  175. >side effects.
  176.  
  177. >>    -don't allocate memory and expected someone else will delete it later. 
  178. >>Can't use OWL, because control classes are automatically deleted for you.
  179.  
  180. >This is very good advice - obviously it doesn't apply for packages such
  181. >as OWL which do it for you.
  182.  
  183. So, how many spaces are in a tab?  Do you leave tabs in or convert
  184. them to spaces?  How many columns long can a line be?  Do you have to
  185. use Hungarian?  COM-interfaces?  Any limits on how many lines or
  186. levels of nesting in a function?  
  187.  
  188. I've seen a lot of standards urged on developers.
  189.  
  190.                         --Norm 
  191.  
  192.